When a user interacts to rewind (RW) or fast forward (FF) a video, some guidance generally needs to be given to the user as to the place that the user is within the video. In this way, the user can find a desired place to begin or resume playing the video. Showing a moving location pointer relative to a timeline or the like is one form of guidance; however, showing representative images provides additional context to help the user decide whether to continue the RW/FF operation as is, or further interact (e.g., speed up or slow down the RW/FF operation, or switch to play).
In recorded video such as on a DVD, the I-frames (“Intra-coded” frames) are already present and serve as a good source of representative location-related images to present to the user. In streaming video provided by video delivery services, another solution is needed, in part because the video cannot be downloaded and/or decoded fast enough to keep up with faster RW/FF operating rates.
One way streaming video services provide such location guidance is to use what is often referred to as “trickplay,” in which the user is occasionally shown a representative “trickplay” image that is fixed (rather than decoded from the video as needed, which is often too slow). The image is taken from a separate set of images, such as assembled into an accompanying file or set of files downloaded to the user.
One streaming video trickplay solution pre-downloads evenly spaced images taken from the source video, with the images typically placed into a single file. However, this solution has drawbacks, primarily because the file download time is relatively large, and trickplay cannot begin until the file is downloaded. To keep the download time tolerable, the image spacing is typically coarse to reduce the number of images, and the quality/resolution of the trickplay images is kept low. To disguise this fact, during trickplay the images that are shown are typically smaller than full screen, e.g., thumbnail images. Significant memory is also consumed to store the images.
Another solution is similar, but prioritizes trickplay images so that images deemed “higher priority” are first downloaded, with such images coarsely spaced in time. Then, to provide finer temporal detail, lesser priority images between those coarsely-spaced images are downloaded thereafter. Again, because a lot of image data still needs to be downloaded, the quality/resolution of the trickplay images is kept low, and a lot of memory is consumed.